The present invention relates to event processing systems and systems that are suitable for electronic business. More specifically, the invention relates to event processing systems which use multiple databases.
With the increasing growth of on-line business and globalization of business, very large accounting systems have become necessary. Such large accounting systems typically require multiple databases, or very complicated programming. In general, the accounting systems must be high performance and able to process an event, as well as access data, very quickly.
It is known to maintain several separate distributed databases having customer-specific data. An additional database having non-customer-specific data may also be maintained. Processing a transaction often requires data that is located in more than one database. For example, a system may need pricing data stored on one database, as well as account information stored on a separate distributed database on which the account resides. When two databases are accessed, a “two-phase commit” procedure is used in order to maintain consistency of the data, as will be appreciated by those skilled in the art. A two=phase commit procedure synchronizes the data and locks both databases for the duration of the transaction. The two-phase commit slows down the transaction, and also makes the databases involved unavailable for other uses. The data synchronization process involves a high overhead that applies to many transactions. Such systems are generally not capable of delivering the fast performance that is increasingly being demanded in large event processing systems.
An additional problem with conventional distributed databases is that operations requiring data from multiple databases are often cumbersome to program. For example, to run billing on all accounts typically requires that a programmer create a billing computer program that is tailored to query each database.
In addition, accounts are typically assigned to a particular database based on an account characteristic, such as billing address. This makes it relatively easy to find the correct database if the characteristic, e.g., billing address, is known. However, finding an account based on a different characteristic, such as a login name, may require a full search. Another disadvantage is that, once chosen, the criteria on which accounts are assigned to a database are inflexible, in order to allow searching based on the criteria to be relatively easy, among other reasons. This creates a potential single point of failure for creation of new accounts and other administrative functions. For example, when each database is assigned to a geographic region, if a database is down, no users from that region may be added to the database.
Accordingly, implementing a multi-database system that is scalable to very large systems; i.e., that has low overhead per transaction and does not use the two-phase commit, would be desirable. It would further be desirable if the system provided data location transparency, and if some flexibility were available in the assignment of customers to a database so that a database is substantially always available for adding new users.